Hello,
I'm aware of how to show traceability within one column using the Wizard...but my question is regarding the other format where it shows the traceability depth in separate columns. For example, say I have an object that has two in-links (call them A, B) and each of those two in-links has several in-links (A has an in-link from C, D and B has an in-link from E, F, G) themselves. If I display using the multiple columns format it's visually hard to see the delineation of the second level in-links to A and B. In other words the wizard will show the main column, then show A, B in the first column, and then in the second column the wizard shows a list of requirements C,D,E,F,G all grouped so it's hard to tell that C and D flow into requirements A...sometimes it looks like C,D,E flows into A etc.
With the single column layout I know that it shows this mapping by indentation...I'm wondering how I can achieve to show this in a multiple layout view.
lsand - Mon Nov 08 14:46:58 EST 2010 |
|
Re: Traceability question
llandale - Mon Nov 08 15:05:35 EST 2010
I can safely say I've never used a 2-level trace, much less more, because its so rediculouosly hard to read and follow. Also, with hyper linked systems you may find 20 or so links just 2 modules away, making the column worthless.
I have used one-level attribute DXL to do this work. Each module has a one-level trace attribute and a 2-level trace attribute. The 2-level trace attribute's job is to poll only one-link away, and summarize the 1-level trace attribute it finds there (if any). Note that each attr-DXL itself only polls one level away, not recursively.
I have found it easier, though, just to write an on-demand script to run each night to do this work and set its own text attributes in each module, making the trace reports accurate to the previous midnight. Folks who make changes and need to see them now can run the script for their modules on demand.
|
|
Re: Traceability question
lsand - Tue Nov 09 18:11:38 EST 2010 llandale - Mon Nov 08 15:05:35 EST 2010
I can safely say I've never used a 2-level trace, much less more, because its so rediculouosly hard to read and follow. Also, with hyper linked systems you may find 20 or so links just 2 modules away, making the column worthless.
I have used one-level attribute DXL to do this work. Each module has a one-level trace attribute and a 2-level trace attribute. The 2-level trace attribute's job is to poll only one-link away, and summarize the 1-level trace attribute it finds there (if any). Note that each attr-DXL itself only polls one level away, not recursively.
I have found it easier, though, just to write an on-demand script to run each night to do this work and set its own text attributes in each module, making the trace reports accurate to the previous midnight. Folks who make changes and need to see them now can run the script for their modules on demand.
I may be misunderstanding or not understanding but here goes..
In the following case:
A that has an in-link from B, C.
B has an in-link from D,E
C has an in-link from E, F, G.
If you have a one-level attribute DXL for the object A, the attribute DXL will show a one-level trace (B, C). If you have a one-level trace from (B,C) then the result would return D,E, E, F, G.
How is this different from the wizard?
|
|
Re: Traceability question
SystemAdmin - Wed Nov 10 08:19:24 EST 2010 lsand - Tue Nov 09 18:11:38 EST 2010
Louie,
I may be misunderstanding or not understanding but here goes..
In the following case:
A that has an in-link from B, C.
B has an in-link from D,E
C has an in-link from E, F, G.
If you have a one-level attribute DXL for the object A, the attribute DXL will show a one-level trace (B, C). If you have a one-level trace from (B,C) then the result would return D,E, E, F, G.
How is this different from the wizard?
Well one simple way would be to insert some information regarding the object this information was linked from in the wizard's code... For example:
...
if (depth == 2) {
// BEGIN Parent
s = "Parent: " (identifier o) "\\pard"
display s
// END Parent
s = (identifier othero)
...
That will add the information from where the link originated for each object displayed in the second column... Might be enough.
/Kristian
|
|
Re: Traceability question
llandale - Wed Nov 10 10:49:12 EST 2010 lsand - Tue Nov 09 18:11:38 EST 2010
Louie,
I may be misunderstanding or not understanding but here goes..
In the following case:
A that has an in-link from B, C.
B has an in-link from D,E
C has an in-link from E, F, G.
If you have a one-level attribute DXL for the object A, the attribute DXL will show a one-level trace (B, C). If you have a one-level trace from (B,C) then the result would return D,E, E, F, G.
How is this different from the wizard?
2nd, using the Wizard in A to display objects 2-links away in DEFG creates two columns; the 1st for BC objects and the 2nd with recursion for DEFG objects. My solution ends up similar, but one of the Attr DXL in A is designed to simply query the corresponding attr DXL values in B and C, which themselves poll DEFG for values. This A attr DXL can and should display some simple info of B and C (objID or ReqID) before displaying their DEFG values, making the display MUCH easier to understand.
One problem with this is when A is linked to two B objects, each of which are linked to the same D object. In this case, that D object gets displayed twice. That can be solved with my scheme, but if you really only want to see that D once then you'd write the wizard kind of code with recursion, accumulating objects to display; then after the main loop add another to do the actual displaying.
|
|
Re: Traceability question
lsand - Wed Nov 10 17:52:01 EST 2010 llandale - Wed Nov 10 10:49:12 EST 2010
First off the Wizard is a Layout which is inferior to Attr DXL in almost every way, ESPECIALLY when it comes to traversing links.
2nd, using the Wizard in A to display objects 2-links away in DEFG creates two columns; the 1st for BC objects and the 2nd with recursion for DEFG objects. My solution ends up similar, but one of the Attr DXL in A is designed to simply query the corresponding attr DXL values in B and C, which themselves poll DEFG for values. This A attr DXL can and should display some simple info of B and C (objID or ReqID) before displaying their DEFG values, making the display MUCH easier to understand.
One problem with this is when A is linked to two B objects, each of which are linked to the same D object. In this case, that D object gets displayed twice. That can be solved with my scheme, but if you really only want to see that D once then you'd write the wizard kind of code with recursion, accumulating objects to display; then after the main loop add another to do the actual displaying.
Question for Louie (or Kristian if it applies):
you mentioned that you have the users run the on-demand script. I'm wondering how you have your DOORS server/client setup. I ask because we have the DOORS server on the network so each user of DOORS has to install the client on their local machine (laptop). when a user logs onto DOORS through the client we found that they can not view the scripts stored on the server UNLESS they remote desktop into the server. Talking to the IBM representative they agreed and said this was the only way.
|
|
Re: Traceability question
llandale - Thu Nov 11 14:03:25 EST 2010 lsand - Wed Nov 10 17:52:01 EST 2010
thanks Louie, and Kristian.
Question for Louie (or Kristian if it applies):
you mentioned that you have the users run the on-demand script. I'm wondering how you have your DOORS server/client setup. I ask because we have the DOORS server on the network so each user of DOORS has to install the client on their local machine (laptop). when a user logs onto DOORS through the client we found that they can not view the scripts stored on the server UNLESS they remote desktop into the server. Talking to the IBM representative they agreed and said this was the only way.
If you cannot see the DXL files with Windows Explorer from your PC then you cannot successfully set up your 'addins' variable to 'install' the menus associated with them. You will need to find some server that allows 'sharing' of one of its folders and put your DXL scripts hierarchy there. Perhaps that is also your DOORS server.
|
|